home *** CD-ROM | disk | FTP | other *** search
Text File | 1987-05-28 | 7.9 KB | 157 lines | [TEXT/Earl] |
- Communication from Earle Horton to Dave Burnard, May 8, 1987
-
- Dave,
-
- Here is microemacs 3.8M, or whatever you want to call it. It
- still has some minor bugs which I can't nail down, but it is
- essentially complete and functional. Major changes I have made
- are inclusion of Lawrence's 3.8b sources, support of window
- resizing and zoom boxes, and support for draft-quality printing on
- a serial device. It should be possible to compile this using MPW
- with relatively little effort. The use of the proper #include
- files is an issue which I ignored, since I do not have MPW, but I
- have tried to be considerate of differences which I could see in
- your source files. Wherever I have noticed it, I have passed
- Points to the toolbox routines using a "Passpt" macro which should
- produce the correct parameter for either LSC or MPW. You should
- NOT use "stdio.h" supplied with MPW, as I use parameter block
- routines for disk IO exclusively.
-
- You should rather use the include file on this disk. I have
- changed the order of #include files from <stdio> first to
- "estruct.h" first. This is because "estruct.h" defines TRUE and
- FALSE, which are redefined in FileMgr.h with Lightspeed C. The
- library file stdio.lib contains some utility functions I wrote
- using MDS, I presume you can assemble and link the source to the C
- routines using the MPW assembler. Note that globals are shared
- between my assembler routines and C. To be honest, the only
- reason to call the #include file stdio.h is so I could have
- something to #include, and so could avoid another set of #defines
- in all the source files.
-
- I have made some changes to TTY_Windows.c to support resizing
- the microemacs window and zoom boxes, and have tried to improve
- handling of update events. (There is a lot of apparent black
- magic involved in handling update events properly.) I have also
- cleaned things up a bit, to the point where Points are accessed
- somewhat more consistently. I split the code into two files,
- because I got tired of memory errors when compiling the program on
- my 512k. I also put the NewTTY_Window() function in a different
- segment, so it could be purged if memory gets tight. A bug that
- exists at this point in the display code is that inverse video
- gets "erased" when another window is brought in front of the mode
- line. I could fix it by using parts of my own display code, but I
- don't feel like it. In my original port, I handled inverse video
- by using InvertRect(), which also works with 64k ROMS. When I did
- this, I never had that problem.
-
- There are two new fields in the "term" structure in 3.8
- (among others). For the width and height there are fields for the
- number of maximum and current rows and columns. A !major! bug in
- 3.8b, which I have fixed, is that during initialization only
- enough memory was allocated for the current number of rows and
- columns. This resulted in a window enlargement causing a system
- crash every time. I didn't annotate this in the source code, I
- just fixed it. There is a bug in your single character output
- routine, which caused output of '\b' to not produce the desired
- effect. I changed some routines in input.c to just put out a
- '\177' and that fixed that.
-
- The emacs window is sized at initialization time now, based
- on the values of qd.screenBits.bounds (just screenBits.bounds to
- LSC). The maximum size is set to 50% wider than the screen width,
- and the number of columns in the "term" data structure is set
- accordingly. You may want to try the following experiment: Drag
- the window to the left by approximately one half of the screen
- width. Resize it to cover the screen. Now hit the TrackBox.
- This could be useful when C programs get indented too far.
-
- There are RMaker (yes, some people still use RMaker) sources for
- the resources I have used. My printing code uses a resource of
- type 'Pcon', but it makes its own, so don't bother with putting in
- a 'Pcon', you don't need to. Here is its structure below. The
- first three fields are determined by what the user inputs to a
- ModalDialog box, the last three are constant, but may be altered
- using ResEdit.
-
- typedef struct{
- int pport;
- int pbaud;
- int pterm;
- int pagelength; /* default, 55 */
- int margin; /* left only, default 8 */
- int tabstops; /* default 8 */
- } pconfig,*Pcfg,**Pfg;
-
- Pagelength is the number of lines between top and bottom margins,
- which are fixed, but a user can change it with ResEdit. Margin is
- left only. Right margin is controlled by window width (a clumsy
- maneuver, but effective). This is primitive code, designed for
- one purpose only, to print source code in draft mode on my Tandy
- DMP 110. I have included enough options so that it should work
- with most ordinary serial printers, however. It is also possible
- to do some clumsy formatting and to access a printer's native
- fonts by embedded control codes. All characters which are in a
- document, except tabs, are sent raw to the printer.
-
- I have included a facility for supporting different printer types.
- Microemacs formats all printed text into strings, with "margin"
- spaces on the left and tabs expanded to eight. A printer setup
- dialog box prompts for baud rate, port, and "Line Terminator".
- Line Terminator may be any one of CR, LF, CRLF, and "User
- Special". If User Special is chosen, then the program looks for a
- resource of type 'ePrc' and ID 777 on the disk. This stands for
- "emacs Printer control" by the way. If this resource is found,
- then emacs sets up a Parameter block (ParamBlockRec) with the
- proper RefNum for the chosen serial port in it. An opcode is put
- in d0, the resource is loaded, and the program calls it as a
- function. There are four opcodes, one of which will be in d0 when
- the resource is called. The meanings are, briefly:
-
- 0: Initialize the printer
- 1: Print out the line contained in ioBuffer(a0),
- whose length is in ioReqCount(a0). Terminate
- the line properly for the printer.
- 2: Do whatever is proper for the end of the page.
- 3: Do whatever is proper for the beginning of the page.
-
- The ePrc resource should have an entry point at the top, end in an
- RTS, and gets no storage, other than what it allocates as a stack
- frame. However, the ioMisc field of the parameter block, unused
- by the device driver routines, points to a longword with nothing
- in it. Since I am not sure precisely what the device driver does
- with this field, the printer command routine should save it in its
- stack frame, and restore it before returning, if it uses it.
- Suggested uses are, call NewPtr, get a pointer to some storage,
- call NewHandle, get a handle to a whole block!
-
- The longword pointed to by the ioMisc field is an application
- global, which I use for no other purpose, so the printer command
- routine can "remember" things in a properly setup block if it
- wants. The routine can have a0, a1, d0, and d1, without restoring
- them. All other registers should be restored upon return. Upon
- entry, a0 points to the io Parameter block, and d0 contains the
- (word) opcode as described above. I have, naturally, included an
- example, written in MDS, which shows exactly how to write a
- printer command resource. Note that if "User Special" is chosen,
- then ALL character output to the printer is actually done by the
- user's routine, so considerable freedom is allowed in what it can
- do.
-
- With Lightspeed C, these sources need to get linked to "MacTraps",
- "strings", and my "stdio" library. I have made some minor changes
- to the regular microemacs sources to avoid linking in "sprintf",
- which yields a great savings in code. Not using the regular
- "stdio" supplied with LSC was an even bigger savings in code size.
- People without hard disks (me) appreciate touches like this. I
- apologize for the lack of a Makefile, but such a thing is not
- needed for Lightspeed, so I just didn't get around to writing one.
-
- Anyway, the program is basically functional, and I have done all
- the work I can on it for a while. Feel free to inspect, post,
- alter, or improve the code in any way that time permits you.
- Thanks for everything.
-
- Earle
-
-